Use unique index for connector pin ports #229
Conversation
formatc1702
force-pushed
the
feature/pin-case-sensitivity
branch
4 times, most recently
from
29b5e36
to
de7f0d8
Compare
Use unique numerical index instead of string (which might cause issues when using pin names that are not unique when ignoring upper/lower case).
formatc1702
force-pushed
the
feature/pin-case-sensitivity
branch
from
de7f0d8
to
1127bcb
Compare
There was a problem hiding this comment.
I like your implementation with a few simple changes to obtain unique port numbers, but I also suggest using one-based port numbers to keep them identical to the pin numbers in the typical case as you describe in #160 (comment). Adding +1 at four locations is enough to ensure this.
If you agree to this, it might also be wise to name the variables pinindex (or pinidx if it must be short) instead of pinid when they contain zero-based pin index numbers. What do you think?
I also suggest updating the type hints of the Cable.connect() parameters and the Connection attributes to reflect their new pin index usage:
PinIndex = int # Zero-based pin index
NoneOrMorePinIndices = Union[PinIndex, Tuple[PinIndex, ...], None] # None, one, or a tuple of zero-based pin indices
so that in the standard case, internal pin IDs match the actual connector's pin numbers, which usually start from 1. Co-authored-by: kvid <kvid@users.noreply.github.com>
as suggested by @kvid. Co-authored-by: kvid <kvid@users.noreply.github.com>
as suggested by @kvid. Co-authored-by: kvid <kvid@users.noreply.github.com>
|
I have implemented your suggestions, please have a look at the updated code. |
formatc1702
force-pushed
the
feature/pin-case-sensitivity
branch
from
13658cb
to
afd4147
Compare
|
My change suggestions have been implemented, and the test cases mentioned in #160 seems to be handled as expected now. When building examples, the |
The change will instead be logged in the `doc/changelog` branch
Closes #160.
Use unique numerical index instead of string (which might cause issues when using pin names that are not unique when ignoring upper/lower case).
This does not address the issue of having special HTML characters as part of pin names, labels, etc. as mentioned in #160 and now listed as #230; there should be a separate PR dealing with escaping these entities in the GraphViz HTML (e.g.
>to>).